DNSSEC はなぜダメなのか

1. DNS に依存している
   • 腐り沈みゆく船 (DNS) の上に継ぎ足しで新しい船を築くのは愚か
2. DNSSEC は難しすぎる
   • 強度の弱い暗号を用いているため、鍵を定期的に更新しなければいけない (そして失敗)
   • 鍵を証明する情報を定期的に上位組織 (委任元) に預けて署名し直してもらわなくてはいけない (そして失敗)
   • ルートの鍵を証明する情報を定期(?)的に世界の検証サーバたちに配布し直さなくてはいけない
   • 運用事業者の移管の際に事業者間で安全に鍵を受け渡すことが困難
   • 運用事業者の移管の際に一旦署名を外すのは安全性と可用性を下げる
   • DNSSEC 署名対応事業者から非対応事業者への移管で事故も起きている
     (移管元も移管先も委任元に預けた鍵情報を消さなかったのが原因 / 一部の有志たちが作成したガイドラインがあって移管先が消すことになっているが非対応の事業者の知ったことではない / 事故をおこしたのは有志も所属している某大手 ISP)
   • 通常の DNS でさえいつも運用失敗による障害を起こしている未熟な技術者たち (浸透という言葉を使うのが特徴) が DNSSEC を運用するのは無理
   • NASA, IETF でも運用に失敗している (月へ行くより難しく規格制定元でも運用できない)
   • 数々の失敗例
   • 無理に DNSSEC を推進することは能力とリソースのある一部事業者 (たとえば Google) への一極集中を招き、自律分散協調のネットワークであるインターネットの崩壊を招く (崩壊しているという説もあるが)
3. DNSSEC の応答はネットの負荷
   • 最近の DNSSEC 対応の DNS キャッシュサーバ実装は自身が検証しなくとも (デフォルトで) 常に署名付き応答を要求する (余計なお節介/それを設定で止められない実装も)
   • DNSSEC の応答はとても大きく効果的な DDoS 源となる (なぜオープンリゾルバだけが責められるのか?) ...(DNSSEC AMP Tool)
   • DNSSEC の大きな応答は UDP において IP パケットをフラグメントさせ受信失敗の可能性をあげる
   • TCP にフォールバックした場合も負荷が大きい (そもそも TCP なら DNSSEC の必要性が下がる)
   • NXNSAttack において、NSEC/NSEC3 により攻撃対象のキャッシュ/権威サーバ間で大きな NXDOMAIN 応答が大量に発生することとなり、問い合わせ数だけでなく応答容量の増幅度も非常に大きくなり、さらに TCP fallback で倍増する可能性も高い
4. DNSSEC は署名の作成や検証の処理が重い
   • 昨今 DNS 水責め攻撃という DDoS 攻撃に権威サーバもキャッシュサーバも苦しんでいるが、DNSSEC はその苦しみを増大させる
   • 2024年2月には KeyTrap という DoS 手法が発表された ...New!
5. DNSSEC は普及を前提に作られていない
   • 不存在証明の仕組みにおいて、現在大多数である未署名な名前領域を列挙することを省略する仕組み (OPTOUT) があり、不存在証明とその署名作成の負荷を減らしているが大量のドメインが署名するようになった場合サーバは耐えられるのか疑問
   • "more then 80% of the TLDs are using NSEC3 and OPT-OUT. If it did not exist most TLDs would not have started using DNSSEC."
6. DNSSEC 至上主義が非対応のドメインを危険にさらしている
   • 非対応のドメインのとるべき毒入れ(キャッシュポイズニング)への防衛策が色々あるにも関わらず、DNSSEC しかないという立場をとっている技術者たちがそれらを実装し広めようとする努力をしていない ( DNS での毒入れ対策の実装を妨げている)
7. DNS キャッシュサーバとクライアントの間は DNSSEC でしか守れないという嘘
   • TLS など暗号化通信路を用意する方法がある
   • 中間者攻撃が可能なネットワークで DNS を守ったところでほとんど意味はない　(その後の通信が中間者攻撃をうける)
8. そもそも DNSSEC で毒入れ (キャッシュポイズニング) を防ぐことはできない (むしろ毒入れされやすくなる)
   • 権威ある応答の署名の検証が可能なだけであり偽委任を防ぐことはできない (偽権威サーバへ誘導する攻撃が可能)
   • 偽権威サーバからの応答は検証可能で失敗するが、毒が効いている間はサービス不能となる (DoS攻撃成功) 　
   • ある条件下での不存在証明に欠陥があり、不存在証明で守られていると思われている名前領域へのキャッシュポイズニングが検証で検出されない可能性(資料p30)がある ...追記:検証しました
     (JPRS に説明と注意喚起を広く行うことを求めているが無視されたまま)
   • DNSSEC で応答サイズが大きくなりパケットが断片化すると第二フラグメントを偽パケットに差し替えられるリスクが高まる (本末転倒)
     2018.10.31 追記: 毒入れ手法の解説を公開しました。
     2019.2.28 追記: 第一フラグメント便乗攻撃(アイコラ攻撃) 解説スライド
     2020.2.29 追記: 論文 "A survey on the status of measures against IP fragmentation attacks on DNS" (Kenya Ota, Tsunehiko Suzuki)
   • ダウングレード攻撃で DNSSEC は無効化できる
9. 署名は行っているが暗号化は行っていない
   • DNSの通信のプライバシーが問題になっている昨今、暗号化も行う DNSCurve という方式も検討すべきだろう (例: dig ns dnscurve.jp)
10. ドメイン名のリストが漏れる
    • 不存在証明のための NSEC によってドメイン名のリストが漏れて悪用される危険性がある
    • NSEC3 で対策されたが困難になっただけでやはり可能 (nsec3walker)
11. 無駄な努力で社会に負荷
    • 列挙したように DNSSEC に労力、コストをかけるのは社会的無駄であり害もある
    • 無駄の極みは逆引きへの適用 (逆引きDNSSECは何のため?)
    • データの真正性 (Integrity) はデータあるいはアプリケーションの層で守ればよいのであって、可用性 (Availability) を落としてまで全てのレイヤで守ろうとするのは技術者たちの我田引水による大いなる無駄 (可用性も真正性や機密性 (Confidentiality) と並ぶセキュリティの三大要素のひとつ)
    • インフラ幻想を捨ててインターノットなんてこんなものという認識で利用するのがよい